Jobs can be delivered to devices such as printers via a data network. In particular, a user delivers a document to a network service. The network service formats the document generating a job that is to be delivered to a particular network enabled device. Firewalls and other security measures prevent a network service from initiating the delivery of a job. However, since the device has no inherent knowledge of when a job is available, the device does not know how or when to request a job, so the device first inquires as to whether a job is ready.
The device may use polling or “hanging get” techniques to learn if a job is ready to be delivered. When polling, the device periodically sends a request to the network device to learn if a job is available, and the server responds. That response either indicates no job is available or, if available, the job is returned in the response. With “hanging get,” the device sends a request to the network service. The service holds on to the request keeping the session open and responds only when a job is available. Or, if too much time elapses, the session times out forcing the device to send another hanging get request.
The polling approach consumes network bandwidth and network service resources when requests are made and no job is available. The bandwidth consumption becomes problematic when polling is implemented on a large scale, that is, when multiple device are polling the network simultaneously. Furthermore, polling results in a job delivery lag. In other words, a job is not delivered until the device sends its next scheduled polling request. The “hanging get’ approach consumes resources of the network service especially when multiple devices are competing for those resources. In particular, the network service maintains a session or thread for each hanging get request.